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Abstract: Web Service orchestrations are compositions of different Web Ser- 
vices to form a new service. The services called during the orchestration guar- 
antee a given performance to the orchestrater, usually in the form of contracts. 
These contracts can be used by the orchestrater to deduce the contract it can 
offer to its own clients, by performing contract composition. An implicit as- 
sumption in contract based QoS management is: "the better the component 
services perform, the better the orchestration's performance will be". Thus, 
contract based QoS management for Web services orchestrations implicitly as- 
sumes monotony. 

In some orchestrations, however, monotony can be violated, i.e., the per- 
formance of the orchestration improves when the performance of a component 
service degrades. This is highly undesirable since it can render the process of 
contract composition inconsistent. 

In this paper we define monotony for orchestrations modelled by Colored 
Occurrence Nets (CO-nets) and we characterize the classes of monotonic orches- 
trations. We show that few orchestrations are indeed monotonic, mostly since 
latency can be traded for quality of data. We also propose a sound refinement 
of monotony, called conditional monotony, which forbids this kind of cheating 
and show that conditional monotony is widely satisfied by orchestrations. This 
finding leads to reconsidering the way SLAs should be formulated. 
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Monotonie dans les orchestrations de web 

services 



Resume : Les orchestrations de services web soiit dcs compositions de ser- 
vices element aires. Ces services, fournissent un 'contrat' a I'orchestrateur, cc 
qui garantit une certaine performance de leur service. Ces contrats sont uti- 
lises par I'orchestrateur pour proposer un contrat a un client pour son propre 
service. Cela se fait par la 'compostion de contrats'. Du point vue de la perfor- 
mance, la composition de contrats suppose implicitement que "L'amelioration 
de la performance d'un service va rendre I'orchestration plus performante" . La 
composition de contrats suppose ainsi que les orchestrations sont " monotones" . 

Dans quelques orchestrations, cependant, la monotonie peut ne pas etre 
respectee. Lorsque la performance d'un service s'amcliorc, la performance de 
I'orchestration sc degrade. Ceci est tres genant car ccla rend le processus dc 
composition dc contrats invalide. Dans ce rapport, nous dcfinissons la mono- 
tonie pour les orchestrations modclisees par des reseaux d'occurrence colorcs 
(CO-nets) et nous caracterisons la classe des orchestrations monotones. Nous 
demontrons que tres peu d'orchestrations sont monotone en pratique, ce qui est 
largement du a la possibilite d'ameliorer la latence en degradant la qualite de 
la reponse donne. Nous proposons ensuite un rafhnement de la monotonie, la 
"monotonie conditionnelle" , qui interdit ce type de 'triche'. Nous montrons que 
la monotonie conditionnelle est tres generalement satisfaite par les orchestra- 
tions. Cette etude nous mene a reconsiderer la formulation des contrats dans le 
cadre des orchestrations de services web. 

Mots-cles : web service, orchestrations, contrats, monotonie 
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1 Introduction 

Web Services and their compositions are being widely used to build distributed 
applications over the internet. Web Service orchestrations are compositions of 
Web Services to form an aggregate, and usually more complex, Web Service 
(WS). The services involved in a WS orchestration may have widely different 
behaviour (both functional and non-functional) and may be separated geograph- 
ically by large distances. 

A WS orchestration is itself a Web Service, and it can be further composed 
with other Web Services to build increasingly sophisticated services. The func- 
tioning of such service compositions can thus be quite complex in nature. There 
is a need to formally describe these systems in order to be able to build and 
reason about them. Different formalisms have been proposed for this purpose, 
the most popular amongst these is the Business Process Execution Language 
(BPEL) [2] a standard proposed by Microsoft and IBM. Another formalism 
is Ore [7] a small and elegant formalism equipped with extensive semantics 
work [ni[Tn|. Various models exist, that have been either used to model directly 
orchestrations or choreographies, or as a semantic domain for some formalisms. 
Noticeably Petri Nets based models, e.g., WorkFlow Nets [Dill] and process 
algebra based models. 

The main focus of the existing models is to capture the functional aspects 
of such compositions. However, non-functional — also called Quality of Service 
(QoS) — aspects involved in services and their compositions need also to be 
considered. The QoS of a service is characterised by different metrics, for e.g., 
latency, availability, throughput, security, etc. Standard WSLA [Ij specifies 
how QoS can be specified using Service Level Specifications and Agreements. 
Examples of SLA parameters are found in this document that illustrate the 
current practice. In particular, "conditional SLA obligations" consist in speci- 
fying what a service must guarantee given that the environment satisfies certain 
assumptions. 
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QoS management is typically based on the notion of contract. Contracts 
are agreements made between the orchestrater and the different actors (the 
called services) involved in the orchestration. Contracts formalise the duties 
and responsibilities each subcontractor must satisfy. For e.g., a service which 
is called in an orchestration can have a contract of the type : for 95% of the 
requests the response time will be less than 5ms. All these contracts with the 
services involved in the orchestration could then be composed by the orchestrater 
to help it propose its own contract with users of the orchestration. This process 
is called contract composition. 

In [S] we introduced the notion of probabilistic contracts to formalise the QoS 
behaviour of services — the work of focused on latency. We showed how these 
contracts can be composed to get the end-to-end orchestration's contract. We 
also showed that realistic overbooking of resources by the orchestrater is possible 
using this approach. 

Contract based QoS management relies on the implicit assumption that, if 
each sub-contractor meets its contract objectives, then so does the orchestrater. 
Vice-versa, a sub-contractor breaching its contract can cause the orchestrater 
to fail meeting its overall contract objectives. Thus the whole philosophy be- 
hind contracts is that the better sub-contractors behave, the better the overall 
orchestration will meet its own contract. In fact, the authors themselves have 
developed their past work [5] based on this credo. . . until they discovered that 
this implicit assumption could easily be falsified. Why so? 




Figure 1: A non-monotonic orchestration 

As an illustration example, consider the orchestration in Figure [1] Services 
M and N are first called in parallel. If M responds first, service S is next called 
and the response of N is ignored. If TV responds first, T is called and not S. 
Let 5i denote the response time of site i. Assume the following delay behaviour 
: 5m < 5n and 5s ^ 5t. Since M responds faster, the end-to-end orchestration 
delay do = 5m + 5s. Now let service M behaves slightly 'badly', i.e delay 5m 
increases and becomes slightly greater than 5n- Now service T is called and the 
new orchestration delay is di = (5jv -f (5t- But since 5s ^ 5t, di is in fact lesser 
than do. This orchestration is non-monotonic since increasing the latency of one 
of its components can decrease the end-to-end latency of the orchestration. So, 
what is the nature of the difficulty? 
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"Simple" composed Web services are such that QoS aspects do not interfere 
with functional aspects and do not interfere with each other. Their flow of con- 
trol is typically rigid and does not involve if-then-else branches. For such cases, 
latencies will compose gently and will not cause pathologies as shown above. 
However, as evidenced by the rich constructions offered by BPEL, orchestra- 
tions and choreographies can have branching based on data and QoS values, 
various kinds of exceptions, and timers. With such flexibility, non-monotony 
such as that exhibited by the example of Figure [T] can very easily occur. 

Lack of monotony, in turn, impairs using contracts for the compositional 
management of QoS. Surprisingly enough, this fact does not seem to have been 
noticed in the literature. 

In this paper we give a classification for orchestrations based on their mono- 
tonic characteristics. Our study focuses on latency, although other aspects of 
QoS are discussed as well. This paper is organised as follows: Section [2] infor- 
mally introduces the notion of monotony with examples. In section [3] we recall 
the definition of Petri nets and colored Petri nets, and introduce our model, 
OrchNet. A formal definition of monotony and a characterisation of mono- 
tonic orchestrations is then given in sectional Section O introduces conditional 
monotony which will be useful to deal with non-monotonic orchestrations which 
use data-dependent control. 

2 Non-monotonic patterns in CO-nets 

We now show examples of non-monotonic orchestrations and identify the source 
of their non-monotony. The necessary and sufficient conditions for monotony 
that we give later were inspired from the study of these patterns. The examples 
we discuss here informally use Petri nets; we believe they are self-explanatory 
and do not deserve formal definitions. The formal definitions of Petri nets and 
their semantics is given in section [31 

Consider the net on Figure[2]with four transitions a, b, c and d with latencies 
Ta, Tb, Tc and Td respectively. Let = 2, t;, = 3, Tc = 4 and = 7. Here a fires 
before b and the overall orchestration latency is Tq + Tc = 6. Now, if t;, = 1, 6 
fires before a and so the orchestration latency is Tb + = 8. Since decreasing 
the latency of b increases the orchestration's latency, the net is not monotonic. 
Non-monotony arises from the fact that the futures of the conflicting transitions 
a and b had different latencies. The net is monotonic if the latencies of c and d 
are constrained to be the same. 




Figure 2: Choices are not monotonic. 
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In Figure [31 transitions a and c arc concurrent, ajj^h and b^j^c. Since we saw 
in the previous example that the futures of conflicting transitions should have 
the same latencies, let us set Td ^ Tp = Tf ~ t^. If Tq = 4,Tf, = 3, Tc = 5, 
b fires first and the overall latency is rt, + Te = 4 + r*. Now if — 2, a 
fires first, b is blocked and c will eventually fire. The overall latency here is 
max{Ta + Td, Tc + Tf) = 5 + T* . Wc thus see that for this net to be monotonic, 
we must have the latencies of the concurrent transitions a and c to be the same 
(along with their futures). In fact, since = Tc and Td = Tf, the two concurrent 
branches can be " folded" into a single branch to give us a net similar to that of 
Figured 




Figure 3: Choice and Concurrency inter-playing 



A monotonic orchestration: Figured] shows an orchestration that has a fork-join 
pattern (in the left). The right side of the figure shows the net's unfolding. (The 
unfolding of a net N is an acyclic net which includes all the possible executions 
of N. Every place in the unfolding can be marked by at-most one transition 
and so every possible way of enabling a transition is distinguished. In Figure HI 
the two possible cases in which event c can be fired are distinguished in the 
unfolded net). Since the left net has a choice pattern, one may think that it is 
not monotonic. However, this is not true. From the previous example we know 
that the unfolded net is monotonic since the futures of the conflicting transitions 
a and b are the same (and hence have the same latencies). 



a 




Figure 4: A monotonic orchestration with a fork-join pattern (left) and its 
unfolding (right). 

At this point we have identified good and bad patterns for monotony. Going 
beyond such simple findings proved to be surprisingly challenging. In particular, 
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characterizing that the restricted class of orchestrations we define is a necessity 
for monotony is demanding. AU this requires more formal material that we 
introduce next. 

3 The Orchestration Model: OrchNets 

In this section we present the orchestration model that we use for our studies, 
which we call OrchNets. OrchNets are a special form of colored occurrence nets 
(CO-nets), which are high level Petri Nets. 

We have chosen this mathematical model for the following reasons. From the 
semantic studies performed for BPEL [51 [3] and Ore [S] [T^ we need to support 
in an elegant and succinct way the following features: concurrency, rich control 
patterns including preemption, and for some cases even recursion. The first two 
requirements suggest using colored Petri nets. The last requirement suggests 
considering extensions of Petri nets with dynamicity. However, in our study we 
will not be interested in the specification of orchestrations, but rather in their 
executions. Occurrence nets are concurrent models of executions of Petri nets. 
As such, they encompass orchestrations involving recursion at no additional 
cost. The executions of Workfiow Nets [HHI] are also (CO-nets). 

3.1 Petri nets, Occurrence nets 

Definition 1 A Petri net is a tuple N = {V,T,!F,Mq), where 

• V is a set of places, 

• T is a set of transitions such that V CiT = 0, 

• T CiV xT)U{T xP) is a set of flow arcs, 

• Mq : V IS! is the initial marking. 

The elements in 'PUT are called the nodes of N and will be denoted by variables 
for e.g, x. For node x G V UT, wc call 'x = {y \ {y,x) S !F} the preset of x, 
and x* = {y \ {x, y) G J-} the postset of x. A marking of the net is a multiset 
M of places, i.e a map from P to N. A transition t is enabled in marking M if 
Vp e 't, M{p) > 0. This enabled transition can fire resulting in a new marking 
AI — 't + t* denoted by M[t)M' . A marking M is reachable if there exists a 
sequence of transitions to, . . . t„ such that Mo[to)Mi[ii) . . . [tn)M. A net is 
safe if for all reachable markings M, M{p) C {0, 1} for all p & V. We define 
two relations on the nodes of a net: 

Definition 2 (Causality) For a net N = (P, T, JF, Mq) the causality relation 
< is the transitive closure of the relation < defined as: 

• Ifp E 't, then p <t, 

• If p E t' , then t ^ p, 
where p E V,t E T. 

The reflexive closure of < is denoted by <. For a node x E P U T, the set of 
causes of x is \x~\ ~ {y E V U T \ y < x}. 
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Definition 3 (Confiict) For a net N ~ {P,T,!F,Mo) two nodes x and y are 
in conflict - denoted by x^j^y - if there exist distinct transitions t, t' G T , such 
that t<x,t'<y and "t n "f ^ 0. 

Nodes X and y are said to be concurrent - written as x\\y - if neither {x < y) 
nor [y < x) nor [x^j^y). A set of concurrent conditions P C P is called a co-set. 
A cut is a maximal (for set inclusion) co-set. 

Definition 4 (Configuration) A configuration of N is a subnet k of nodes 
of N such that: 

1. K is causally closed, i.e, if x < x' and x' E k then a; G k 

2. K is conflict-free, i.e, for all nodes x, x' G k, -^{x^x') 

For convenience, we will assume that the maximal nodes (w.r.t the < relation) 
in a configuration are places. 

Definition 5 (Occurrence nets) A safe net N = (7^, T, JF, A/q) is called an 
occurrence net (0-nct) iff 

1. -i{xffx) for every x E V U T . 

2. < is a partial order and \t~\ is finite for any t £ T . 

3. For each place p Cz V, \'p\ < I. 

4- Mq = {p £ Vl'p = 0}, i.e the initial marking is the set of minimal places 
with respect to <Ar- 

Occurrence nets are a good model for representing the possible executions of a 
concurrent system. Unfoldings of a safe Petri net, which collect all the possible 
executions of the net, are occurrence nets. Unfoldings are defined as follows. 

For N and N' two safe nets, a map 93 : PUT i-^ is called a morphism 

of N to N' if: 1/ ip{V) C V' and (p{T) C T , and 2/ for every t G T and 
t' = ip{t) G T', *t U {t} U f is in bijection with *t' U {t'} U t'* through (p. 

Now, for N a safe net, there exists pairs (?7, ip) where U is an occurrence 
net and ip : U 1-^ iV is a morphism — the places and transitions of U arc 
"labeled" with places and transitions of TV through morphism if. The unfolding 
of N, denoted by {Un, ^n) or Un for short, is the smallest pair {U, ip) with the 
above properties, where smallest refers to inclusion up to isomorphism. The 
configurations of Um are the executions of A'', seen as partial orders of events. 

Figure [5] shows a safe net A^ and a small part of its unfolding Un- A step in 
the construction of Um is shown in the figure on the right. In each such step, a 
set of concurrent conditions X in Um are chosen such that <p(A') = 't for some 
transition t in A^. The set of nodes X U {t'} U t'* are then added to Um where 
p{t') = t and ip{t'') = t* . The right figure shows the addition of a new copy of 
transition a (along with its preset and postset) to Um- 

Any place of an occurrence net (specifically, an unfolding) gets a token at- 
most once. We can thus talk about " the token of the place" unambiguously for 
any place in these nets. 
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Figure 5: Construction of the unfolding Un of a safe net N. 
3.2 Our Model: OrchNets 

We now present the orchestration model that we use for our studies, which we 
call OrchNets. OrchNets are occurrence nets in which tokens are equipped with 
attributes (or colors). Figure El shows an OrchNet equipped with attributes 




Ts I S I t I Tt 

( case d < d! then d + Ts 
E = I case d > d' then d' + Tt 



I otherwise nondeterministic 

Figure 6: A Generic Transition of our Model. The arc expressions are shown 
next to the arcs and the guard expression is written next to the transition. 
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related to timing. Places are labeled with dates which is in fact the date of the 
token of that place. Transitions arc labeled with latencies. The tokens in the 
three minimal places are given initial dates (here, (^0,^1,^2). The four named 
transitions m, n, s and t are labeled with latencies Tm, Tn, Ts and Tt respectively, 
and the two shaded transitions have zero latency. 

The presence of dates in tokens alters the firing semantics slightly. A transi- 
tion t is enabled at date when all places in its preset have tokens. It then takes 
Tt additional time to fire. For example, the shaded transition in the left has all 
its input tokens at inax.{d2,do+Tm} and so it fires at max{(i2, do +''m} + since 
it has zero latency. If a transition fires at date d, then the tokens in its postset 
have the date d. This is shown in the figure, e.g., on the place following the left 
shaded transition, which has date max{(i2, do + Tm}- 

When transitions are in conflict, (e.g., the two shaded transitions in Fig- 
ure [6|) , the transition that actually occurs is governed by a race policy [6] . If 
a set of enabled transitions are in conflict, the one with smallest date of oc- 
currence will fire, preempting the other transitions in conflict with it. So, in 
Figure El the left shaded transition or the right shaded transition will fire de- 
pending on whether d < d' or d > d' respectively, with a nondeterministic choice 
ii d = d' . This results in selecting the left most or right most continuation (firing 
s or t) depending on the above cases. The resulting overall latency E of the 
orchestration is shown at the bottom of the figure. 

In addition to dates, tokens in OrchNets can have data attributes, which 
we call values. We have not shown this in Figure [H in order to keep it simple. 
Values of tokens in the preset of a transition t can be combined by a value 
function (pt attached to t. The resulting value is taken by the token in the 
postset of t. 

Transitions can also have guards (the presence of such a guard is not neces- 
sary) . Guards are boolean predicates involving values of the tokens in the tran- 
sition's preset. A transition is enabled only if its guard is true. An "If(cond)- 
then-else" branching can be implemented by using the following mechanism: 
Put a place p, followed by two transitions t,t'. Guard t with the predicate 
"cond=true" and t' with the predicate "cond=false" . 

At this point we are ready to provide the formal definition of OrchNets: 

Definition 6 (OrchNet) An OrchNet is a tuple N' ^ (iV, $, T, Tinit) consist- 
ing of 

• An occurrence net N with token attributes c = {value, date). 

• A family <I> = {(f)t)t£T of value functions, whose input parameters are the 
values of the transition's input tokens. 

• A family T = {TtjteT of latency functions, whose input parameters are the 
values of the transition's input tokens. The range of the latency functions 
zs m R U {-l-oo} 

• A family Tjnit = (''p)pGmin('P) of initial date functions for the minimal 
places of N . The range of the initial date functions is m RU {-t-oo} 

We do not specify a concrete range of value functions since they can be any 
arbitrary value and this is not of direct importance in the sequel. How a tran- 
sition t modifies the attributes of tokens is formalized now: Let the preset of 
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t have n places whose tokens have (value, date) attributes (vi,di) . . . {vn,dn). 
Then all the tokens in the postset of t have the pair (vt, dt) of value and date, 
where: 

Vt = (/)t(fi . . .u„) 

dt = max{di . . . dn} + Tt{vi . . . Vn) (1) 

The race policy during execution is formalized as follows: In any given marking 
M, let T be the set of transitions that are possibly enabled, i.e. Wt G T, 't is 
marked in M . Then the transition t that is actually enabled, (which really fires) 
is given by: 

t = argmin dt 

teT 

where argmin f{x) ~ x* e X s.t. Vx' G X,f{x*) < f{x'). 

If two transitions have the same dt, then the choice of the transition that 
actually fires is non-deterministic. If for a transition t, the delay dt is infinite, 
it is equivalent to saying that transition t does not occur. 

The choice extensions to occurrence nets in OrchNets is inspired by the 
application domain: compositions of web services. It reflects the following facts. 

• Since we focus on latency, [value, date) is the only needed color. 

• Orchestrations rarely involve decisions on actions based on absolute dates. 
Timeouts are an exception, but these can be modelled explicitly, without 
using dates in guards of transitions. This justifies the fact that guards 
only have token values as inputs, and not their dates. 

• The time needed to perform transitions does not depend on the tuple of 
dates (di . . .dn) when input tokens were created, but it can depend on the 
data (vi . . . Vn) and computation </> performed on these. This justifies our 
restriction for output arc expressions. 

If it is still wished that control explicitly depends on dates, then dates must 
be measured and can then be stored as part of the value v. 



Actually Occurring Configuration and Execution Time In general, 
both value and latency functions can be nondeterministic. We introduce an 
invisible daemon variable lo that resolves this nondeterminism and we denote 
by its domain. For a given value of lu, the value and latency functions (f>f and 
Tt are deterministic functions. 

Let TV = (iV, $,T, Tinit) be a finite OrchNet. For a value uj £ fl for the 
daemon we can calculate the following dates for every transition t and place p 
of A/": 

^ , , f '''p if p is minimal 

^ [ dsibj) where s — 'p otherwise (2) 

df (oj) = max{dn{u}) \ n G 't} + t^{vi, . . . u„) 

where Vi, . . .Vn are the value components of the tokens in *t as in equation ([1]). 
If K is a configuration of N, the future TV" is the OrchNet (iV, $Ar-< , Tat^ , T(^-^) 
where and T^tk are the restrictions of $ and T respectively, to the transi- 
tions of N'^. T/jjj is the family derived from M according to ([2]): for any minimal 
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place p of A^", the initialisation function is given by r^^^ — dp{uj). For X a set 
of nodes of N, let 

%nin{x) = {teT{x)\"tnx = 9} 

Now define inductively, 

Ko{uj) — 

K„i{uj) = K„i_i(tj) U {tm} U 'i™ U i,„' (3) 

where i,„ = arg min dt{uj) 

ter„i„(jv""-i<'^') 

Since net A'^ is finite, the above inductive definition terminates in finitely many 
steps when TV^"*'") = 0. Let M{uj) be this number of steps. We thus have 

= KO C Kl(tj) • • • C KM(uj)ioj) 

K.M{ui) ('^) is a maximal configuration which actually occurs according to our 
timed semantics, for a fixed ld. Each step decreases the number of maximal 
configurations sharing K,n.{Lo) as a prefix. We denote by k(7V, w), the maximal 
configuration K}^,[^^^'^ [u) that actually occurs. 
For a prefix B of N define 

E^{B,Af) = max{d^(w) \ x e B} (4) 

If i? is a configuration, then E^^ {B,J\f) is the time taken for B to execute (latency 
of B). The latency of the OrchNet Af = {N, $, T, Tinit), for a given uj is 

4 Characterizing monotony 

In this article, we are interested in the total time taken to execute a web- 
service orchestration. As a consequence, we will consider only orchestrations 
that terminate in a finite time, i.e, only a finite number of values can be returned. 

4.1 Defining monotony 

To formalize monotony we must specify how latencies and initial dates can 
vary. As an example, we may want to constrain some pair of transitions to have 
identical latencies, or some pair of minimal places to have identical initial dates. 
This allowed flexibility in setting latencies or initial dates is formalized under 
the notion of pre-OrchNet we introduce next. 

Definition 7 (pre-OrchNet) Call pre-OrchNet a tuple N = (TV, $, T, Tinit); 
where N and $ are as before, and T and Tinit o,re sets of families T of latency 
functions and of families Tinit of initial date functions. Write Af G N if Af ^ 
{N, $, T, Tinit) for some T e T and Tinit G Tinit. 

For two families T and T' of latency functions, write 

T > T' 
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to mean that G r2,Vt G T => Tt{uj) > T/(a;), and similarly for Tjnit > ^I'nit- 
For A/", TV' G N, write 

A/'> AA' 

if T > T' and Tinit > I]nit both hold. 

Definition 8 (monotony) pre-OrchNet N = (TV, T, Tjnit) is called mono- 
tonic if, for any two MM' G N, such that Af > J\f' , we have E^{M) > E^{M'). 

Considering legal sets T and Tjnit of families of latency functions and initial 
date functions allows setting constraints on these families. This possibility will 
be essential in characterizing monotonic orchestrations. 

4.2 A global necessary and sufficient condition 
Theorem 1 

1. The following condition implies the monotony of pre-OrchNet N — (N, $, T, Tjnit) ■ 

VA/'gN, Vcj g 17,Vk g V(7V), . . 

E^kM) > E^{k{N,uj),N) ^ ' 

where V (N) denotes the set of all maximal configurations of net N and 
k(A/', cj) is the maximal configuration of N that actually occurs under the 
daemon value to. 

2. Conversely, assume that: 

(a) Condition ^ is violated, and 

(h) for any two OrchNetsN and J\f' such that M G N, then J\f' > M =^ 
N' G N. 

Then N ~ {N, $,T, Tjnit) is not monotonic. 

Sub-condition b) in statement [2] destroys the necessity of Condition ([5]). State- 
ment [2] expresses that Condition ^ is also necessary provided that it is legal to 
increase at will latencies or initial dates. Observe that Condition ^ by itself 
cannot be enough since it trivially holds if T is a singleton. 

Proof: We first prove Statement □ Let A/"' G N be such that A/"' > TV. We 
have: 

E^{k{M\u;),M') > EUk{M',u;),M) 

> E^{ii{N,oj),M) 

where the first inequality follows from the fact that 'K{JV,uj) is a conflict free 
partial order and TV' > TV, and the second inequality follows from ([5]) applied 
with K = 'K{J\f' This proves Statement [TJ 

We prove statement [U by contradiction. Let (TV, (jJ,k^) be a triple violating 
Condition ([5]), in that 

cannot occur (6) 
E^ (T^t ,M)<E^ (k(A/', ^)M) (7) 
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Now consider the OrchNct net M' ^ {N,^,T', Tinit) where the family T' is the 
same as T except that in to, Vt ^ t/(w) > E^{K\j\f). Clearly M' > M. But 
using construction ([3]), it is easy to verify that 'k{JV,lij) — and thus 

< E^{K{Af,uo),M), 
which violates monotony. O 



4.3 A structural condition for the monotony of workflow 
nets 

Workflow nets |llj were proposed as a simple model for workflows. These are 
Petri nets, with a special minimal place i and a special maximal place o. We 
consider the class of workflow nets that are 1-safe and which have no loops. 
Further, we require them to be sound |llj . 

Definition 9 A Workflow net W is said to be sound ifl^: 

1. For every marking M reachable from the initial place i, there is a firing 
sequence leading to the final place o. 

2. If a marking M marks the final place a, then no other place can in W can 
be marked in M 

3. There are no dead transitions in W . Starting from the initial place, it is 
always possible to fire any transition of W . 

An example of workflow net is shown in the first net of Figure U) Workflow 
nets will be generically denoted by W . We can equip workflow nets with same 
attributes as occurrence nets, this yields pre-WFnets W = (ly, $, T, Tinit)- Re- 
ferring to the end of Section 13.11 unfolding W yields an occurrence net that we 
denote by N\y with associated morphism ipw : Nw ^ W, see Figure ID Here 
the morphism ipw maps the two c transitions (and the place in its preset and 
postset) in the net on the right to the single c transition (and its preset and 
postset) in the net on the left. Observe that W and Nw possess identical sets 
of minimal places. Morphism ipw induces a pre-OrchNet 

nw = (iVH/,$H/,Tv^,Tinit) 

by attaching to each transition t of Nw the value and latency functions attached 
to ipwit) in W. 

We shall use the results of the previous section in order to characterize those 
pre-WFnets whose unfoldings give monotonic pre-OrchNets. Our characteriza- 
tion will be essentially structural in that it does not involve any constraint on 
latency functions beyond equality constraints, for some pairs of transitions. Un- 
der this restricted discipline, the simple structural conditions we shall formulate 
will also be almost necessary. 

We first define a notion of cluster on safe nets, which will be useful for our 
characterisation. 
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Definition 10 (clusters) For a safe net N, a cluster is a minimal set c of 
places and transitions of N such that 

e c =^ c c , Vp e c =^ c c (8) 

Theorem 2 (Sufficient Condition) Let W be a WFnet and Nw be its un- 
folding. A sufficient condition for the pre-OrchNet Nw = [Nw , i^w 
to be monotonic is that every cluster c satisfies the following condition: 

Vii,i2ec, ti^t2 =^ tl'=t2' (9) 

Proof: Let ipw be the net morphism mapping Nw onto W and let A/" G N 
be any OrchNet. We prove that condition [1] of Theorem [T] holds for M by 
induction on the number of transitions in the maximal configuration k(A/', uj) 
that actually occurs. The base case is when it has only one transition. Clearly 
this transition has the least latency and any other maximal configuration has a 
greater execution time. 

Induction Hypothesis Condition [T] of Theorem [T] holds for any maximal 
occurring configuration with m — 1 transitions (m > 1). Formally, for a pre- 
OrchNet N = (TV, $, T, Tinit): VA/" e N,Vw G 17,V7« G V(iV), 

E^inM) > E^{n{N,u),M) (10) 

holds if |{t G k{M,uj)}\ < m - 1. 

Induction Argument Consider the OrchNet A/", where the actually occurring 
configuration 7;(A/', uj) has m transitions, k! is any other maximal configuration 
of A/". If the transition t in K{J\f,u!) with minimal date dt also occurs in n' then 
comparing execution times of k(A/', lu) and k' reduces to comparing Ei^{'K{Af, uj)\ 
{t},Af*') and E^{k' \ {t},A/'*). Since K{J\f,u}) \ {t} is the actually occurring 
configuration in the future TV* of transition t, using our induction hypothesis, 
we have 

EUn^,i^) \ {t},M') < E^{n' \ {t},N') 

and so 

E^{k{N,uj),M) <E^{k',N) 

li t ^ k' for some k', then there must exist another transition t' such that 
't n 't' ^ 0. By the definition of clusters, fwit) and ipw{t') must belong to 
the same cluster c. Hence, t* ~ t'' follows from condition [2] of Theorem [51 The 
futures A/"* and A/"* thus have identical sets of transitions: they only differ in 
the initial marking of their places. If Tinu and T/^^j are the initial marking of 
these places, Tinu < ^Xiit (since dt < c?t', t* has dates lesser than t'*). Hence 

E^iKif^,u;),M) = E^(KiM,u)\{t},M') (11) 

and 

i?^(At',A/-) = EU^i'\{t'},M'') 

> E^iK'\{t'},f^') (12) 
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The inequahty holds since A/"* > A/"*. The induction hypothesis on pT|) and 
dm) gives 

This proves the theorem. o 

Comments about tightness of the conditions of Theorem [2] Recall that 
the sufficient condition for monotony stated in Theorem [T] is "ahirost necessary" 
in that, if enough flexibility exist in setting latencies and initial dates, then it is 
actually necessary. It turns out that the same holds for the sufficient condition 
stated in Theorem [2] if the workflow net is assumed to be live. 

Theorem 3 (Necessary Condition) Suppose that the workflow net W is sound. 

Assume that W G W and W" > W implies W £ W, meaning that there is 
enough flexibility in setting latencies and initial dates. In addition, assume that 
there is atleast one W* G W such that there is an daemon value lu* for which 
the latencies of all the transitions are finite. Then the sufficient condition of 
Theorem\^is also necessary for monotony. 

Proof: We will show that when condition ^ of Theorem [2] is not satisfied 
by W, the Orchnets in its induced preOrchNet Nw can violate condition (O of 
Theorem [U the necessary condition for monotony. 

Let cw be any cluster in W that violates the condition [5] of Theorem [51 
Consider the unfolding of W, Nw and the associated morphism ip : Nw W 
as introduced before. Since W is sound, all transitions in cw are reachable 
from the initial place i and so there is a cluster c in Nw such that ip{c) = cw ■ 
There are transitions t\,ti e c such that *t\ n '^2 7^ 0, ''/'(^i) ^ 'fit-i) 7^ and 
ip(ti)' ^ (p{t2)*. Can [t] = [t] \ {t} and define K = [ti] U [t2]. We consider the 
following two cases: 

K is a configuration If so, consider the OrchNet Af* £ Nw got when transi- 
tions of Nw (and so W) have latencies as that in W*. So for the daemon value 
uj*, the quantity E^*{K,Af*) is some finite value n*. Now, configuration K can 
actually occur in a OrchNet TV, such that TV > TV*, where TV is obtained as 
follows (t and r* denote the latencies of transitions in TV and TV* respectively): 
V< e K,t' e Nw s.t. 't n 't' ^ 0, set Tt'{uj*) n* + 1 and keep the other 
latencies unchanged. In this case, for the daemon value w*, the latencies of all 
transitions of TV (and so its overall execution time) is finite. Denote by TV^ 
the future of TV once configuration K has actually occurred. Both t\ and t2 are 
minimal and enabled in TV^. 

Since 1^5(^1)* 7^ •-pit^)* ^ without loss of generality, we assume that there is a 
place p e t\* such that ^p{p) S H^{f\)* but '^(p) ^ ipit^)* ■ Let t* be a transition 
in TV^ such that t* G p*. Such a transition must exist since p can not be a 
maximal place: 'piji) can not be a maximal place in W which has a unique 
maximal place. Now consider the Orchnet TV' > TV got as follows: t[^(uj*^ = 
Tti(tJ*),r4(w*) = T(,(w*) + 1 and for aU other t G c,t[(uj*) = r^Jw*) + 1. Set 
t/. (w*) = 00 and for all other transitions of TV', the delays are the same as that 
in TV and thus are finite for w*. 
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ti has the minimal delay among all transitions in c, and t* is in the future 
of ti. So the actually occuring configuration E^*{'K{Af' ,uj*),Af') has an infinite 
delay. However any maximal configuration k which does not include ti (for 
eg, when t2 fires instead oi ti) will have a finite delay. For such k we thus 
have E^.i'KiM' ,uj*),N') > E^^.(ji,J\f') and so M' violates the condition ([5]) of 
Theorem [TJ 

K is not a configuration If so, there exist transitions t G \ [^2], t' G 
[^2] \ [h] such that 't n 't' ^ 0, Xi) n V(t') ^ and ip{t)' ^ (p(i')'- The 
final condition holds since t2 and ti are not in the causal future of t and t' 
respectively. Thus t and t' belong to the same cluster, which violates condition 
iniof Theorem [5] and wc can apply the same reasoning as in the beginning of the 
proof. Since [t] is finite for any transition t, we will eventually end up with K 
being a configuration. o 

4.4 Discussion regarding monotony 

Based on the mathematical results of the former section, we shall first discuss 
which orchestrations are monotonic. The resulting class is not very wide, as we 
shall see. However, further thinking suggests that considering QoS parameters 
in isolation — as we did so far — is not the right way to proceed. We will thus 
revisit QoS and monotony. 

Which orchestrations are monotonic? Not surprisingly, orchestrations 
involving no choice at all — they arc modeled by event graphs — arc monotonic. 

Theorem[21 however, allows for more general orchestrations. In particular, if 
multi-threading with only conflicting threads are used, then the theorem essen- 
tially requires that the choice among the different threads is performed, based 
on their overall latency (where a thread is considered as atomic). It is allowed, 
however, that conflicting threads possess different overall latencies. Next, if a 
blend of concurrent and conflicting multi-threading is used, then 1 / concurrent 
threads should have equal latencies, and 2/ the choice among conflicting threads 
should be based on their overall latency. Finally, concurrent multi-threading 
(with no conflict with other thread when the concurrent threads arc launched) 
raises no problem. An example of a non trivial monotonic orchestration is shown 
in Figure m 

Revisiting QoS and monotony As discussed before, orchestrations involv- 
ing data dependent control will very often be non monotonic. This makes 
SLA/SLS/contract based QoS management very problematic. What did we 
wrong? 

In fact, the problem is that we consider QoS parameters in isolation when 
dealing with SLS or contracts. However one can trade latency for "quality of 
data" . Typically, by reducing timeouts while waiting for responses from called 
Web services, one can easily reduce latency. But there is no free lunch: if one 
does so, then exceptions get raised in lieu of getting valid responses for the 
query. 

So we must refine our notion of monotony as follows: say that an orchestra- 
tion is "conditionally monotonic" if, under the constraint that identical responses 
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are received by the orchestration, increasing some latency will cause an increase 
of the overall latency of the orchestration. In the next section we formalize this 
notion and study the characterization of conditional monotony. 

5 Refined QoS and Conditional monotony 

Define the set of values returned by a maximal configuration k G V (Af) as 



where max(K) denotes the maximal (w.r.t <) transitions in the configuration k. 
The values returned by the orchestration A/" = (iV, 0, T, Tinn) for a given value 
of the daemon u is 



Definition 11 (conditional monotony) pre-OrchNet N = (A^, <&, T, Tjnit) is 
called conditionally monotonic if, 



Definition [TT] does not attempt to compare overall orchestration latencies, if 
different responses are received as a result of changing latencies of called Web 
services. In particular, cases where valid data are received are not compared 
with cases where exceptions are raised. Said differently. Definition [Tl] prohibits 
trading latency for quality of data. 

Conditional monotony docs not seem to be considered while formulating 
WSLA contracts. The 'conditional' contracts in WSLA arc not related to the 
notion of conditional monotony but rather refer to the obligations that need to 
be met by the client for the server's promises to be fulfilled. 

Assumption 1 We assume that OrchNet N is such that for all distinct k, k' G 



Assumption [T] is very natural when normal processing of the orchestration to- 
gether with cases where exceptions occur are considered. With this assumption, 
Theorem [T] simplifies as follows: 

Theorem 4 Under Assumption [1\ pre- OrchNet N ~ (iV, $, T, Tinit) is condi- 
tionally monotonic. 

Proof: In fact this is a trivial result: by Assumption [TJ we do not need 
to compare latencies across different configurations. But each configuration 
possesses no conflict and is therefore an event graph. Since dating in event 
graphs is amenable of max /+ algebra, it is monotonic. Thus pre-OrchNet 
N = {N, $,T,Ti,iit) is conditionally monotonic. o 



{iptiuj) I t G max(K)} 



K.(«(A/-,w),AA) 
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6 Conclusion 

This paper is a contribution to the fundamentals of contract based QoS manage- 
ment of Web services orchestrations/choreographies. QoS contracts impHcitly 
assume monotony w.r.t. QoS parameters. This paper focuses on one specific 
(but representative) QoS parameter, namely latency or response time. We have 
shown that monotony is very easily violated in realistic cases. We have formal- 
ized monotony and have provided necessary and sufficient conditions for it. As 
we have seen, QoS can be very often traded for Quality of Data: poor quality 
responses to queries (including exceptions or invalid responses) can be obtained 
typically much faster. This reveals that QoS parameters should not be consid- 
ered separately, in isolation. We have thus revisited the notions of latency and 
monotony and proposed the new concept of conditional monotony. Fortunately 
enough, typical orchestrations turn out to be non-monotonic, but conditionally 
monotonic. 

Our study has an impact on the way SLS should be phrased for orchestra- 
tions: it suggests crude contracts such as "for 95% of the requests the response 
time will be less than 5ms" should not be used without referring to the quality 
of data. Also, our study has an impact on contract monitoring — monitoring 
whether a called service meets its contract. 

We see two extensions of this work. First, our mathematical results rely on 
the notion of branching cells, which were developed for nets without read arcs. 
However, advanced orchestration languages such as Ore [3 offer a sophisticated 
form of preemption that requires contextual nets (with read arcs) for their mod- 
eling. Extending our results to this case is non trivial since branching cells do 
not exist for contextual nets. Second, this paper considers latencies in a non 
probabilistic context. However, these authors advocated in [S] the use of proba- 
bilistic contracts — they better reflect the uncertain nature of QoS parameters 
in the open world of the Web and they allow for well sound overbooking and less 
pessimistic contracts. We should extend our present work to this probabilistic 
framework. This should not be too difhcult, as we guess. In fact, a theory of 
monotony for probabilistic QoS must rely on an order among probability distri- 
butions. This exists and is known as stochastic ordering. Results are available 
that relate stochastic ordering and point- wise ordering (as we study here), which 
should be of help for such an extension. 
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